Machine virtualization has become a common way to present the physical resources of a computer as virtual machines (VMs) within which guest operating systems may execute. Typically, a virtualization layer manages sharing of a computer's hardware resources among VMs executing on the computer. The virtualization layer might be a hypervisor, a virtualization module in an on-the-metal kernel, or other privileged software that manages execution of VMs.
One advantage of machine virtualization is that different entities or tenants can share the resources of a same computer. In addition, a virtualization host (a computer hosting VMs) can be managed by one entity (e.g., a host administrator) and the VMs on the host, including their guest software, can be managed by entities other than the host administrator. That is to say, machine virtualization can be commoditized by one entity (e.g., a virtualization or cloud vendor) and consumed by other entities (VM tenants).
This ability of physical machines to be shared among different entities offers advantages and disadvantages. One advantage is that utilization levels of computer hardware can be maximized. This economic efficiency benefits vendors and tenants. Another advantage is that tenants can avoid the cost of managing hardware and virtualization software. The vendor administers the hardware and virtualization environment and the tenants administer their individual VMs and/or guest software thereon. The different roles of vendors and tenants is also a disadvantage. A vendor usually has administrators with privileged administrative accounts on the virtualization hosts that execute the tenant VMs. A vendor with such kernel-level privileges can access static and dynamic data of tenant VMs. For example, a vendor/host administrator might be able to mount and read a tenant VM's virtual disks. When a tenant VM is executing, an administrator might be able to access the hardware through which the VM's data flows; privileged access may allow a host administrator to access a VM's memory space, for instance. Even if a VM's memory or virtual disk is somehow secured or shielded from host administrator access, a VM's network communications may be vulnerable. A host administrator might easily tap into a VM's network communications as they pass through the VM's host machine.
Although there are techniques for securing network communications, the known techniques have drawbacks only appreciated by the instant inventors. It is possible for guest software in a VM to encrypt its network communications. Known protocols such as Secure Hypertext Transport Protocol (HTTPs), Internet Protocol Security (IPSec), and the like have been used to provide end-to-end per-flow or per session encryption. However, such encryption at the transport, network, and/or application layers has shortcomings. Encryption is performed on a per-application or per-connection basis and encrypting all of a VM's network communications may be difficult or impossible. Encryption at the physical/media layer has also been used, but communication payloads are exposed before they enter (and after they exit) the encrypted media segment. Furthermore, over time, current encryption measures may become obsolete, vulnerabilities may arise, new applications might need to be manually configured for encryption, etc. Avoiding security lapses may require regular administration by tenants.
The inventors have appreciated that there is a need to secure a VM's network communications in ways that are transparent to the VM and that avoid exposing cleartext (or weakly encrypted) VM communications to host administrators, in particular where a VM's communications flow through the VM's host between the VM and the host's physical network interface card (NIC).